State-Driven Testing of Distributed Systems: Appendix

This appendix describes the system model that is adopted for the experimental evaluation of our state-driven testing approach. Moreover, it contains the glossary of the terms used in the paper. 1 System model The system model adopted for state-driven testing is showed in Figure 1. Transitions in the Petri Net represent events that can occur during an execution. These events are logged by the Workload Generator during an execution, in order to infer the evolution of the system and to identify whether a target state has been reached. Events are logged by instrumenting the application code in key points, such the entry and exit points of methods of CORBA objects. Table 1 briefly describes the meaning of the considered events: they are related to requests issued by processes in the system, the completion of requests, and lock/unlock operations performed by the Façade on FDP Tables. In Figure 1, transitions and places are grouped on the basis of their relationships with components of the FDPS (Client, Façade, Processing Server, Load-Balancing Service). The places in the uppermost part of the system model represent the state of the FDP Table in the Façade process: in particular, the number of tokens in places A1 . . . A6 represent the number of enqueued requests for the FDP number 1 . . . 6. When a request is sent from the Façade to a Processing Server, a token is removed from one of the places B1 . . . B6, and a token is added in the place BF1. In turn, a token is added to one of the places WRK1,WRK2,WRK3 according to a load-balancing strategy, which reflect the state of Processing Servers (busy or idle). When a Processing Server finishes, it invokes a callback method of the Façade, which unlocks the FDP and allows the system to process the next pending request for that FDP. 2 D. Cotroneo, R. Natella, S. Russo, F. Scippacercola